User Stories in Agile
When working on a products functionality one of the most important aspects is the user story. A user story is used to describe just how a user or customer will use the product. And as such it is often told from the user’s perspective. If you need to focus on a particular functionality like searching for a product or booking and appointment, a user story can be used for that as well. However you should not be writing a user story if you don’t know who you are writing for or what they want, so proper research if necessary before you can even start with writing the user stories. Personas are a great tool that can be used to capture the possible insights of a client. A persona is a fictional character that consists of a name, picture, certain characteristics, behavior and attitudes as well as the goal the persona wants to achieve. A goal can also be a problem that needs to be solved with the product. One of the most important things to remember about user stories is that they are not meant to be a specification but rather a collaboration tool. They should not be used by the development team, but rather used to reduce the amount of overhead and speed up delivery by keeping an only the relevant information. A benefit of user stories is that they are easy to understand. This comes from them being kept simple and concise and not including jargon or confusion and possibly ambiguous terms. One thing to note is there is no one way to write user stories. Some teams will be more comfortable with a certain technique, or some products, problems or stories will require different techniques. Don’t be afraid to experiment and see what works for you and your team. If you are having difficulty with coming up with user stories one way to get starting is to use epics. An epic is basically one big, overarching, sketchy story. It is over time broken up into user stories, but it is a good way to get a basic idea of what kind of features you want to include in a product without having to commit to details just yet. Over time an epic will also help to address what is most important to the client and the users and allows you to write user stories based off those. Once you have your epics and have started to refine them, it’s time to break it into several smaller, but far more detailed user stories. Then go over the user stories, adding detail to them and refining them until they are clear and testable. By this point the entire development team should have a grasp on what you are trying to do with each story and then break the story up in necessary so it will fit within a sprint. With the epics now broken up into the more manageable and workable user stories, you should add acceptance criteria to help complement the narrative. These will allow you to better describe what condition must be fulfilled before the user story can be considered completed. And important aspect of user stories is that they are collaborative, along with most things in Agile. This means that you should not hide the stories, but rather keep them visible so that everyone can benefit from them and accelerate the progress of the project. This will help ensure that every one is on the same page, as well as keeping work moving at a manageable pace. Lastly an important thing to keep in mind is that while user stories are important and valuable, they should not be the only thing you use. User stories are most useful when describing product functionality, but there is so much more to a product then just how or if it works. Therefore keep an eye out for other things that can be useful to supplement the user stories and don’t be afraid to experiment.